dashboard: a slow data run can't hold the page's refreshes - #214

Fixes the dashboard Chrome tests' flakiness on Node 24: "the note typed" and "1 polls" timeouts in kit (24, rest), which hit #203 three times in four and #204 once. They weren't caused by the code: `dashboard-data` takes about 255 ms on the typing fixture on every branch. The cause was a stall that also affects the owner's real dashboard on a loaded box.

Why it stalled. The page runs one `/api/data` read at a time, and its fetch had no timeout. The server shares one `dashboard-data` child across every page and gives it 120 s. One slow or stuck child stopped every refresh for up to 2 minutes, so each 15 s wait in the tests failed in turn.

The fix

• Server. A read that has last good data to fall back on waits `DATA_WAIT_MS` (20 s; `DEVTEAM_DATA_WAIT_MS`, where 0 means no wait) on the shared run. After that it answers with the fallback data, marked `x-devteam-stale`. The run carries on and a later read gets its result. The first read, with nothing to fall back on, still waits for the run. An empty output is never kept as good data.
• Page. Once data is drawn, a refresh gives up after 30 s and says the server didn't answer, so the one-at-a-time guard can't hold. It reads the body before applying the headers, so a read that's given up sets nothing.
• Press safety, checked in review. A press that reads stale data after writing still shows as done. `ANSWERED` latches until the question is gone from a reply, and overlays skip their time-expiry while `STALE` is set.

Diagnostics. The fixture's fetch hook records each data read. A page wait that times out now reports the last five reads (a stuck one with how long it has been in flight) and the end of the dashboard server's output, so a future failure shows whether the child hung or crawled.

Tests

• New: "a slow data run…", run with `DEVTEAM_DATA_WAIT_MS=0`. The first read is fresh; a read during a run returns the last good data, marked stale; the run's result arrives on a later read.
• Node 24 locally: dashboard 113 pass, the rest of the suite 374 pass, bounds 3 pass, none failing.

Review. Fable did an adversarial review. Fixes in the second commit: wait parsing that turned empty or NaN into 0, header state left half-applied after a give-up, empty output treated as good data, the hook comment, and the env scrub. One judgement call is left open: a stale reply has no visual cue on the page beyond the "updated" time. That predates this change; it just happens more often now on a project whose runs take over 20 s.

🤖 Generated with Claude Code